Consider a digital system wherein a communications path, such as a bus, transmits both a clock and some accompanying data. Typically, the phase of the clock is delayed by a half-cycle of the data, so that the data has time to set up, whereupon a transition in the clock indicates that it is time to capture the value of the data, which might be a logical ONE or a logical ZERO. As is well known, temperature variations, power supply drift, higher speeds, longer data paths, wider bus widths and inter-symbol interference all conspire to degrade timing and voltage margins, leading to various strategies of compensation. One such strategy is to periodically train the receiver mechanism by transmitting a known pattern of data, whereupon the receiver adjusts itself to register the correct results. Another is to continuously monitor transitions in the data and deliberately variously delay the clock transition by an amount that produces the needed half cycle.
These techniques can benefit from a first hand knowledge of the unit interval of the data signals on the bus. The unit interval (UI) is the length of a data bit, or the transition-to-transition cycle time, and is also subject to variations influenced by variations in temperature, power supply voltages, etc. It can also happen that UI(ONE) [the unit interval of a ONE] might not be the same as UI(ZERO) [the unit interval of a ZERO]. Thus, it would be desirable if the receiver could periodically, or on an as-needed basis, discover the actual unit intervals UI(ONE) and UI(ZERO), and do so in a fashion that lends itself to subsequent identification of the points in time that are at the middle of the effective (or equivalent) unit interval (say, of an average of UI(ONE) and UI(ZERO), in order to clock the data capture mechanism at exactly those times). A worthy goal, indeed, but it requires that we actually perform an onboard measurement of UI(ONE) and UI(ZERO). What to do?